-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Use lockfiles when determining what packages changed across commits #3250
feat: Use lockfiles when determining what packages changed across commits #3250
Conversation
@chris-olszewski is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
6 Ignored Deployments
|
…kspace-filters-use-of
…kspace-filters-use-of
a00f42c
to
664038a
Compare
…kspace-filters-use-of
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple questions but this makes sense overall.
return resolvedPkgs, nil | ||
} | ||
|
||
func transitiveClosureHelper(wg *errgroup.Group, pkg *fs.PackageJSON, lockfile lockfile.Lockfile, unresolvedDirectDeps map[string]string, resolvedDeps mapset.Set) { | ||
for directDepName, unresolvedVersion := range unresolvedDirectDeps { | ||
directDepName := directDepName |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the purpose of these lines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't copy the values here then it'll resolve as the same value in every iteration of the loop: https://github.com/golang/go/wiki/CommonMistakes#using-reference-to-loop-iterator-variable
I'm so excited for Rust
pkg.TransitiveDeps = append(pkg.TransitiveDeps, lockfilePkg.Key) | ||
pkg.Mu.Unlock() | ||
resolvedDepsSet.Add(fmt.Sprintf("%s@%s", lockfilePkg.Key, lockfilePkg.Version)) | ||
resolvedDeps.Add(lockfilePkg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How come we can get rid of the lock here? Is it because we're only mutating resolvedDeps
now? Are there any race conditions due to the wg.Go
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we needed the lock because each goroutine that was spun up via the working group could try to append TransitiveDeps
and go slices aren't thread safe. mapset.Set
is threadsafe so we don't need to lock anything up
…kspace-filters-use-of
…kspace-filters-use-of
…mits (#3250) This PR attempts to address #2162 This PR was written to be conservative by nature and it will mark packages as changed on almost any lockfile change that isn't just a version bump. Notable changes: - Extended SCM interface as we need to be able to reconstruct old lockfile - Refactored calculation of the transitive closure of the package graph so a full `Context` object isn't required - Merged `TransitiveDeps` and `ExternalDeps` as they contained almost identical information I haven't been able to fully test this, but from a quick spot check of pnpm it seems to behave as expected. Needed testing: - [x] Npm - [x] Yarn - [x] Yarn2+ - [x] Pnpm
This PR attempts to address #2162
This PR was written to be conservative by nature and it will mark packages as changed on almost any lockfile change that isn't just a version bump.
Notable changes:
Context
object isn't requiredTransitiveDeps
andExternalDeps
as they contained almost identical informationI haven't been able to fully test this, but from a quick spot check of pnpm it seems to behave as expected.
Needed testing: